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This document specifies an Internet standards track protocol for the 
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improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2005). 
Abstract 


This document provides details of the Voice Profile for Internet Mail 
(VPIM) directory service. The service provides the email address of 
the recipient that is given a telephone number. It optionally 
provides the spoken name of the recipient and the media capabilities 
of the recipient. 


The VPIM directory Schema provides essential additional attributes to 
recreate the voice mail user experience using standardized 
directories. This user experience provides, at the time of 
addressing, basic assurances that the message will be delivered as 
intended. This document combines two earlier documents, one from 
Anne Brown and one from Greg Vaudreuil, that define a voice messaging 
schema into a single working group submission. 
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1. Scope 


1.1. Design Goals 


The VPIM directory Schema (VPIMDIR) is accessed from outside the 
enterprise or service provider domain using the recipient’s telephone 


number. 


els Performance Constraints 


Once the identity of the VPIM directory server is known, the email 
address, capabilities, and spoken name confirmation information can 


be retrieved. This query is expected to use LDAP [LDAP], a 


connection-oriented protocol. The protocol transaction includes 
multiple packet round-trips to execute the query and retrieval and is 


considered to be the highest latency element of the messaging 


service. Further, retrieval of the confirmation information may 


require the return of a spoken name segment of up to 20kbytes 


(5 


seconds at 4kbytes/second). Over a sufficiently engineered Internet 
connection, a 1250 ms response time is believed to be achievable over 


the Internet at large. 
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1.3. Scaling Constraints 


A service provider’s namespace is expected to include entries for 
tens of millions of subscribers in a flat namespace based on the VPIM 
inter-domain address form: telephone_number@domain_name. A large 
corporation may have a hundred-thousand entries, while a large 
service provider may have tens of millions of entries in a single 
domain. It is expected that there will be a single public address 
validation service for a given service provider’s network. It is 
believed that existing directory technology, including horizontal 
scalability through replication, will provide sufficient transaction 
throughput within the required latency requirements to address this 
need. The only fundamental, new requirement this application imposes 
on directory servers, beyond similar existing services, is the 
ability to return the recipient’s spoken name. Preliminary 
investigation suggests that storage and retrieval of a spoken name 
will not add appreciable latency; however, it will add to the need 
for storage capacity. 


1.4. Reliability Constraints 


DNS provides well-documented redundancy and load-balancing 
capabilities for the VPIMDIR. However, the latency requirements to 
the end-user may not permit client-side fail-over to a secondary 
server and may require the directory server to be implemented as a 
high-availability service. 


2. The VPIMUser Directory Schema 


(IANA-ASSIGNED-OID.1 NAME ’vPIMUser’ 

SUP ‘top’ 

AUXILIARY 

MUST ( vPIMRfc822Mailbox $ 
vPIMTelephoneNumber ) 

MAY ( vPIMSpokenName $ 
vPIMSupportedUABehaviors $ 
vPIMSupportedAudioMediaTypes $ 
vPIMSupportedMessageContext $ 
vPIMTextName $ 
vPIMExtendedAbsenceStatus $ 
vPIMMaxMessageSize $ 
vPIMSubMailboxes ) ) 


When present, the vPIMUser object contains information useful for 
verifying that the dialed telephone number corresponds to the 
intended recipient. This object also provides capability information 
and mailbox status information useful for guiding composition by the 
sender and for setting delivery expectations at sending time. 
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2.1. vPIMTelephoneNumber 


The attribute vPIMTelephoneNumber is the full E.164 form of the 
telephone number [E164], including any sub-addressing portion. The 
normal search will be for this attribute. 


(IANA-ASSIGNED-OID.2.1 NAME /’/vPIMTelephoneNumber’ 
EQUALITY caseIgnoreMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} ) 


Example: A North American telephone number with the sub address of 12 
would be represented as "4121455512124+12". 


Note that vPIMTelephoneNumber is, by default, a multi-valued 
attribute. But if an entry has multiple values for this attribute, 
those values MUST be distinct from each other in the telephone number 
portion. It is expected that each submailbox of a single telephone 
number will have its own vPIMUser entry. 


The vPIMTelephoneNumber differs from telephoneNumber in [LDAP] in its 
support for sub-addressing information and its use as a voice 
messaging address. In most cases, these values will be the same. 


The telephone number is stored with no parenthesis, spaces, dots, or 
hyphens. The leading ’+’ and the ’+’ delineating the submailbox are 
required markup. 


2.2. VPIMRfc822Mailbox 


The attribute vPIMRfc822Mailbox stores the inter-domain SMTP address 
of the voice mailbox associated with a given telephone number. It is 
defined as a distinct attribute to distinguish it from the 
rfc822Mailbox attribute that may be used for other purposes. 

Although it would be preferable to define vPIMRfc822Mailbox as a 
subtype of rfc822Mailbox, it is defined here as an entirely new 
attribute because some directory implementations do not support sub- 


typing. 


(IANA-ASSIGNED-OID.2.2 NAME /’/vPIMRfc822Mailbox’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) 


2.3. vPIMSpokenName 


The vPIMSpokenName attribute is an octet string and MUST be encoded 
in 32 kbit/s ADPCM exactly, as defined by [32KADPCM]. vPIMSpokenName 
shall contain the spoken name of the user in the voice of the user. 
The length of the spoken name segment MUST NOT exceed five seconds. 


Vaudreuil Standards Track [Page 4] 


RFC 4237 Voice Messaging Directory Service October 2005 


Private or additional encoding types are outside the scope of this 
version. 


(IANA-ASSIGNED-OID.2.3 NAME ’vPIMSpokenName’ 
EQUALITY octetStringMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000} 
SINGLE-VALUE ) 


2.4. wvPIMTextName 


The text name is designed to be consistent with the unstructured 
text name databases used for calling name delivery service of 
caller ID. 


(IANA-ASSIGNED-OID.2.4 NAME ’vPIMTextName’ 
EQUALITY caseIgnoreMatch 
SYNTAX. 1.3.6.1.4.1.1466.115.121.1.15{20} 
SINGLE-VALUE ) 


2.5. vPIMSupportedAudioMediaTypes 
The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of 


audio encodings that can be received at the address specified in 
vPIMRf£c822Mailbox. 


(IANA-ASSIGNED-OID.2.5 NAME /’/vPIMSupportedAudioMediaTypes’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


This is a multi-value attribute. The allowable values for this 
attribute are the MIME audio subtypes registered with IANA. Non- 
standard and private encoding types must be indicated by prepending 
the new type name with either "X-" or "x-". 


Because ADPCM is a required format, the audio32kadpcm value must be 
listed if this attribute is present. 


2.6. vPIMSupportedMessageContext 


The message context provides guidance to the sender about the message 
contexts the recipient is likely to accept. Message context provides 
less precise information about a given recipient’s capabilities than 
a list of media types. However, given the growing role of media- 
conversion gateways, the context indicator provides more useful 
guidance to a sender in a "unified messaging" environment. 
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(IANA-ASSIGNED-OID.2.6 NAME ’vPIMSupportedMessageContext’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


This is a multi-value attribute. The set of valid message context 
values is defined in [CONTEXT]. 


2.7. vPIMExtendedAbsenceStatus 


It is common to have an attribute that indicates to the subscriber 
whether the recipient is accepting messages during his absence. This 
feature -- called "extended absence" -- provides an advisory message 
at sending time. It is similar in concept to "vacation notices" 
common for textual email, but has its own cultural and operational 
nuances. 


(IANA-ASSIGNED-OID.2.7 NAME ’vPIMExtendedAbsenceStatus’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
SINGLE-VALUE ) 


The three values defined are: 
"Off", "On", "MsgBlocked" 


"Off" indicates that the recipient either does not support extended 
absence or has not set such an indicator. "Off" is the default 
condition if this attribute is not returned. 


"On" indicates that the recipient has set an extended absence 
indicator, but the mailbox is still accepting messages for review at 
an unspecified future time. 


"MsgBlocked" indicates that the recipient has set an extended absence 
indicator and the mailbox is currently configured to reject incoming 
messages. Messages SHOULD NOT be sent to the recipient if this value 
is returned in the vPIMExtendedAbsenceStatus attribute. 


2.8. vPIMSupportedUABehaviors 


Internet mail does not provide facilities for the sender to know 
whether the recipient supports a number of optional features that can 
be requested or indicated in the RFC822 headers. This attribute 
provides a list of the attributes, considered optional by VPIM and 
other vendor-specific attributes, that may be supported by the 
recipient. If this attribute is not supported, only those attributes 
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listed as mandatory in VPIM are assumed to be supported. Undisclosed 
behaviors may be indicated in the RFC822 message; however, there is 
no assurance by the receiving system of their support. 


(IANA-ASSIGNED-OID.2.8 NAME ’/vPIMSupportedUABehaviors’ 
EQUALITY caseIgnoreIA5Match 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


The following behaviors are defined: 


MessageDispositionNotification 
MessageSensitivity 
MessageImportance 


The presence of the MessageDispositionNotification value indicates 
that the recipient will send an MDN in response to an MDN request. 


MessageSensitivity indicates that the recipient fully supports the 
sensitivity indication as defined in VPIM [VPIMV2]. 


MessageImportance indicates that the recipient fully supports the 
importance indication as defined in VPIM [VPIMV2]. 


These may be further extended without standardization to include 
proprietary user interface functional extensions. These proprietary 
extension values must be prefixed with an "X-" or "x-". 


2.9. vPIMMaxMessageSize 


At the time of composition, the message can be checked for acceptable 
length using the maximum message size attribute. Maximum message 
size is an attribute usually configured by policy of the receiving 
system, typically in units of minutes. While ESMTP provides a 
mechanism to determine if a message is too long in bytes, it is an 
unreliable guide for the composer when multiple encodings, multiple 
media, or variable bit-rate encodings are supported. 


(IANA-ASSIGNED-OID.2.9 NAME ’vPIMMaxMessageSize’ 
EQUALITY integerMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 
SINGLE-VALUE ) 


The attribute indicates the maximum message length in seconds that 
the receiving mailbox may receive. 
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2.10. vPIMSubMailboxes 


This attribute indicates the presence of sub-mailboxes for the 
queried telephone number. This information may be used to provide a 
post-dial sub-addressing menu to the sender. 


(IANA-ASSIGNED-OID.2.10 NAME ’vPIMSubMailboxes’ 
EQUALITY numericStringMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} ) 


The allowable values include a list of sub-mailbox numbers with a 
numeric range of 1-9999. The user interface may use this information 
to prompt the sender to select a sub-mailbox. Spoken names 
associated with each sub-mailbox may be individually retrieved by 
subsequent queries to the recipient’s VPIMDIR service. 


3. Security Considerations 
The following are known security issues. 


1) Service provider customer information is very sensitive, 
especially in this time of local phone competition. Service 
providers require maximum flexibility to protect this data. 
Because of the dense nature of telephone number assignments, this 
data is subject to "go fish" queries via repeated LDAP queries to 
determine a complete list of current or active messaging 
subscribers. To reduce the value of this retrieved data, service 
providers may limit disclosure of data that is useful for 
telemarketing, such as the textual name, and may disclose only 
information useful to the sender, such as the recipient’s spoken 
name, a data element that is much harder to auto-process. 


2) In many countries, there are privacy laws or regulations that 
prohibit disclosure of certain kinds of descriptive information 
(e.g., text names). Hence, server implementors are encouraged to 
support DIT structural rules and name forms [LDAPMODELS] as these 
provide a mechanism for administrators to select appropriate 
naming attributes for entries. Administrators are encouraged to 
use these mechanisms, access controls, and other administrative 
controls, which may be available to restrict use of attributes 
containing sensitive information when naming entries. 


3) The LDAP directory service needs to be secured properly for this 
intended use. [LDAPAUTH] describes a number of considerations 
that apply in this use. In particular, this service provides 
unauthenticated, public access to directory data, and as such, it 
is vulnerable to attacks that redirect the query to a rogue server 
and offer malicious data. 
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4. IANA Considerations 
Reference RFC 3383 "Internet Assigned Numbers Authority (IANA) 
Considerations for the Lightweight Directory Access Protocol (LDAP)" 
[LDAPREG]. 

4.1. Object Identifiers 


IANA has registered an LDAP Object Identifier for use in this 
technical specification, according to the following template: 


Subject: Request for LDAP OID Registration 

Person & email address to contact for further information: 
Greg Vaudreuil (gregv@ieee.org) 

Specification: RFC 4237 

Author/Change Controller: IESG 

Comments: 


The assigned OID will be used as a base for identifying a number of 
schema elements defined in this document. 


4.2. Object Identifier Descriptors 


IANA has registered the LDAP Descriptors used in this technical 
specification, as detailed in the following template: 


Subject: Request for LDAP Descriptor Registration Update 

Descriptor (vPIM): see comment 

Object Identifier: see comment 

Person & email address to contact for further information: 
GregV@ieee.org 

Usage: see comment 

Specification: RFC 4237 

Author/Change Controller: IESG 


Comments: 
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The following descriptors have been added: 


NAME Type OID 
vPIMUser O IANA-ASSIGNED-OID.1.1 
vPIMRfc822Mailbox A IANA-ASSIGNED-OID.2.1 
vPIMTelephoneNumber A IANA-ASSIGNED-OID.2.2 
vPIMSpokenName A IANA-ASSIGNED-OID.2.3 
vPIMSupportedUABehaviors A IANA-ASSIGNED-OID.2.4 
vPIMSupportedAudioMediaTypes A IANA-ASSIGNED-OID.2.5 
vPIMSupportedMessageContext A IANA-ASSIGNED-OID.2.6 
vPIMTextName A IANA-ASSIGNED-OID.2.7 
vPIMExtendedAbsenceStatus A IANA-ASSIGNED-OID.2.8 
vPIMMaxMessageSize A IANA-ASSIGNED-OID.2.9 
vPIMSubMailboxes A IANA-ASSIGNED-OID.2.10 
Where Type A is Attribute and Type O is ObjectClass 
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